Subject: Re: IBM DLSw activity

From: Choon Lee <[email-masked]>
Date: Mon, 10 May 1993 13:56:06 -0700

David,

In the ethernet environment where source routing is not used, how does one
prevent a TEST frame from being "sent across" (via CANUREACH) the
DLS more than once, thus causing loops?

Regards,
choon lee
[email-masked]

---

From: "Jim (J.) Cobban" <[email-masked]>
Date: Tue, 11 May 1993 11:54:00 +0000

>There was a question awhile back regarding TEST frames and SDLC.  The 6611 MPQP adapter
>will reject a received TEST frame as a protocol violation.  Yes, use of the TEST
>frame is architected;  however, it is never used.  Most devices (if not all) do not
>send/receive TEST frames on SDLC lines.
>

If taken literally this statement is totally wrong.  In fact I am not aware
of a single IBM implementation of SDLC which does not send and receive TEST
frames (except, obviously, the 6611).  I must assume that the word
"unsolicited" was omitted by accident from the above statement.

Since the current 6611 only supports the attachment of secondary stations
then it is true that as long as the 6611 does not transmit a TEST frame, it
should never receive a TEST frame.  However all devices which can be attached
to a 6611 in this manner will correctly respond to a TEST frame if one is
sent to them.  It could be perceived as a product limitation that the 6611
does not provide this diagnostic test.  Since the 6611 is such a new product,
and since it is being sold into a market which has not been characterized by
the need to be able to manage large numbers of low-speed, low-quality lines it
is understandeable that it omits a considerable part of the traditional
diagnostic capabilities of SNA equipment.

The discussion of TEST frames arose specifically in connection with SDLC to
SDLC connections, and distinct from the requirement for support of T2.1.  It
is therefore clear that the support which is requested here is specifically
in relation to the 37xx NCP link level 2 test.  

There are, it would appear, several aspects to the area of level 2 loop-back
testing.  The TEST frame is a somewhat inadequate tool because it does not
provide a mechanism for exp[licitly specifying the point at which loop-back
is to occur.  For an SDLC connection which traverses a router network it
would clearly be desireable to be able to:

   1) run a loop back test from the FEP port to the entry port to the router
      network.
   2) run a loop back test from the FEP port to the exit port from the router
      network.
   3) run a loop back test from the FEP port to the destination PU.

   +------+  SDLC  +------+  DLS   +------+  SDLC  +------+
   | 3745 |--------| 6611 |--------| 6611 |--------| 3174 |
   +------+        +------+        +------+        +------+
          <----1--->
	  <-------------2----------------->
	  <-------------------3-------------------->

The only obvious way to distinguish between these three tests is by using
different station addresses.  For management purposes it would also make
sense that the 6611 which is attached by an SDLC link to the host should also
have its own PU appearance.  Distinguishing between case 2 and case 3 is more
complicated because they are both carried over the same DLS connection, and
therefore would require two station addresses for each DLS connection.

Now that we have muddied the waters with TEST frames, how about LPDA?  If
there are diagnostic modems attached to the remote link, how could the
operator on the host run an end-to-end diagnostic test?

---

From: [email-masked]
Date: Tue, 11 May 93 09:41:03 PDT

>in relation to the 37xx NCP link level 2 test.  

[ *** remainder of Jim's response deleted *** ]

I agree with Jim's assessment.  SDLC TEST frames can't be ignored.

Cisco's SDLC-to-SDLC implementation in STUN (serial tunneling) treats
XID and TEST identically and handles each transparently when local
ack'd.  This means that they are merely passed through end-to-end in
all states without the routers trying to diddle with them.  Both TEST
and XID can happen at any time (e.g. non-negotiation XID3 exchange) and
only the SNA end systems care about their content.

As I indicated in an email last week, I will document cisco's basic
STUN functionality for the DLSw SIG effort.  It's been in the field now
for 2+ years and is used for PU4-to-PU2, PU4-to-PU4, and NT2.1-to-NT2.1.

Regards,
-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627

---

From: "Shannon Nix" <[email-masked]>
Date: Tue, 11 May 93 16:53:30 EST

FLOW CONTROL:

It seems to me that the ENTER_BUSY and EXIT_BUSY signals are both reactive 
and redundent.  The combination of PREQ and PRSP bits and the IPM signal 
provide an adequate and deterministic mechanism.  When one end station 
enters a busy state ( RNRs), then the participating DLSwitches can "push 
back" to the source end station using only the pacing mechanism.  Provided 
the queing mechanisms in the DLSw implementations use a fair, preallocated 
buffer algorithm, then this is deterministic and should not consume 
excessive buffer resource in either DLSw.  The ENTER_BUSY-EXIT_BUSY 
mechanism does not seem necessary and, as Dennis pointed out, has a number 
of flaws and race conditions.

Q:  In the absence of capabilities exchange, how are the initial pacing 
window sizes negotiated?

SDLC TEST COMMANDS:

Traditionally the TEST command has been used by SDLC devices to diagnose 
connectivity and its use is not restricted to circuit establishment.  
While I agree with Wayne and Jim that SDLC TESTs shouldn't be ignored, I 
think that they should be responded to locally by the boundary 
DLSw.  It may not even be another SDLC connection at the other 
boundary.

SDLC LINK STARTUP SEQUENCE:

As Paul pointed out, depending on the devices or configuration, there are a 
variety of flows which may bring an SDLC link to a contacted state. For 
each of those, there is more than one sensible way for an implementor to 
map the interaction onto the state machine described in RFC 1434.  
For instance, the implementation described by David describes a perfectly 
reasonable way for a leased SDLC link activation to pass through a DLSw 
cloud.

I cannnot think of an SDLC implementation which could not be 
reasonably mapped onto RFC1434's state machine and, therfore, I 
don't believe that RFC 1434 needs to be enhanced to support SDLC ( at least 
not in the area of link establishment).

XID3 NEGOTIATION:

To the extent that this is possible, I think these should be allowed to 
flow end-to-end.  There are, however, some fields which a DLSw is
required to or may want to "diddle" with:

 - ABM capable bit 
 - Max frame size (MAXDATA)
 - Receive window size (MAXIN)
 - Link station role

I agree with Wayne that RFC 1434's state machine should allow an XIDFRAME 
input in the CONNECTED state ( non-activation XID exchanges).

Q:  If neither end station is a NT 2.1, and, therefore, cannot negotiate 
the max frame size, does the DLSw have to do segmentation and reassembly 
(or segmentation minimally)?  Having written this down I've now convinced 
myself that this is an implementor's choice as well.

LPDA:

Great question Jim!  How does the 6611 handle this?

Rgds, Shannon
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)(*)   Shannon Nix    (*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)      Netlink, Inc.     (*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  3214 Spring Forest Rd.   (*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  Raleigh N.C. 27604 USA   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Phone:  (919)-878-8612   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Fax:    (919)-872-2132   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*) Internet: [email-masked] (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)